One of the most important stages in the software development cycle is the debugging stage that occurs after a software product has been shipped to customers. This stage is important because the actual experiences of users of the software product may be utilized during this stage to isolate program errors, identify frequently or infrequently used features, and to generally make the software product better and more stable.
The main focus of analysis in the after-release debugging stage is typically to identify the program errors (also referred to as “bugs”) that occur most frequently. By identifying the most frequently occurring bugs and fixing them, the usability experience of many users can be improved. There is another category of analysis, however, that has been generally unaddressed by previous after-release debugging systems. This category involves identifying computer “hangs.” Hangs are periods of time in which the software ceases to respond to user input and ceases to redraw the display screen.
Although a hung computer program continues to execute, the program is typically completely unresponsive to the user because no input is received and the display is not updated. This can be extremely frustrating for a user because it may be unclear to the user as to whether the program has encountered a fatal error from which it will not recover, or whether the program will complete its processing and again receive input and update the display screen. If the period of unresponsiveness is extended, the user may believe that the computer program has encountered a fatal error and choose to terminate the program. Terminating a hung program in this manner can result in the loss of data and an unstable system state.
If the portion of a computer program that is causing the unresponsive behavior can be identified, any one of a number of steps can be taken to improve the responsiveness of the program code. For instance, the unresponsive portion may be rewritten to perform its processing asynchronously or on a background processing thread. Alternatively, if the unresponsiveness is being cause by performing processing on the program's main message loop, the processing can be moved out of the message loop. Other types of changes to the program may be made to improve the responsiveness of a computer program once the portion of the computer program causing the unresponsive behavior has been identified. Accordingly, there is a need for a method, system, and apparatus for identifying unresponsive portions of a computer program. There is also a need to monitor such performance issues as they are encountered by actual users and to do so in a way that does not degrade application performance or the user experience.
It is with respect to these considerations and others that the various embodiments of the present invention have been made.